home *** CD-ROM | disk | FTP | other *** search
- Path: engnews1.Eng.Sun.COM!taumet!clamage
- From: clamage@Eng.sun.com (Steve Clamage)
- Newsgroups: comp.std.c++
- Subject: Re: Throwing an exception from within a si
- Date: 22 Jan 1996 16:23:06 GMT
- Organization: Sun Microsystems Inc.
- Approved: clamage@eng.sun.com (comp.std.c++)
- Message-ID: <4e0d5d$47h@engnews1.Eng.Sun.COM>
- References: <4dumo5$bav@wcap.centerline.com>
- Reply-To: clamage@Eng.sun.com
- NNTP-Posting-Host: taumet.eng.sun.com
- Content-Type: text
- X-Nntp-Posting-Host: taumet.eng.sun.com
- Content-Length: 1950
- X-Lines: 41
- Originator: clamage@taumet
-
- In article bav@wcap.centerline.com, chase@centerline.com (David Chase) writes:
- >
- >Use of techniques not mandated by the ABI does not necessarily
- >"violate" the ABI. For instance, Sun's current C++ product uses
- >PC-ranges, yet these are not discussed in the ABI. Note that the C++
- >subroutines interoperate with ABI-conforming subroutines. Placing
- >something like that in the ABI merely helps reduce the chance that
- >each and every language and vendor will do something different and
- >non-interoperable.
-
- I'm afraid it does more than that. Suppose PC-ranges are not in the ABI
- and a C++ program uses functions (like the C library or the X library or
- a database library) which were not written or compiled as C++ and thus do
- not have PC-ranges.
-
- If an asyncronous signal occurs during execution of a non-C++ routine, and
- the signal handler is a C++ routine that throws an exception, what will
- happen if the stack is not in a consistent state?
-
- Guarantees in the C++ standard about exceptions in signal handlers would be
- tantamount to saying that C++ programs cannot expect to call non-C++ functions.
-
- The C standard does not even promise that you can call an arbitrary
- function from a signal handler. How can C++ make stronger promises?
-
- On a given platform, an implementation may provide documented
- behavior for what the standard says is undefined, and in fact that is
- often the case. For example, some invalid floating-point operations have
- undefined behavior, but many implementations provide well-defined
- mechanisms for dealing with FP errors. Most platforms define how pointer
- and integer types may be inter-converted. You just can't count on these
- things in portable code.
-
- Similarly, if it made sense on a given platform to allow arbitrary code in
- signal handlers, the implementation could document that fact. Requiring
- such from every implementation on every platform is a different story.
-
- ---
- Steve Clamage, stephen.clamage@eng.sun.com
-
-
-
- [ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
- Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
- is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
-
-